This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress.

If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged.

If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack.

Thank you! ❤️

Size Change: -1.22 kB (-0.07%)

Total Size: 1.74 MB

_{compressed-size-action}

We don't want to undo any reduction in specificity, we just want to put it at a level that is the same or higher as the reset styles. We don't want to revert global styles specificity reduction.

I don't have enough context on why this change is needed, so a fuller description on this PR, or link to an issue, would be much appreciated!

I'm not sure how much fuller I can make it, but I'll try. When there are reset styles at the element specify level, they will overrule any zero specificity global styles?

My understanding of the proposal is that:

• All generated styles still need to have the same specificity
• A revert of #60106 would result in varied selector specificity (see button block)
• This PR would only bump the uniform specificity to a degree that prevents reset styles from overriding block styles

So if that's correct, I don't think a revert is required but there might be some additional tweaks required for the block library styles for core blocks.

This does still provide a general reduction in specificity, unfortunately, not to zero as we would in an ideal world starting from scratch.

Flaky tests detected in f1b413f.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/9221646544
📝 Reported issues:

• [Flaky Test] Items list is reachable via TAB #61701 in /test/e2e/specs/site-editor/dataviews-list-layout-keyboard.spec.js

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ellatrix <ellatrix@git.wordpress.org>
Co-authored-by: aaronrobertshaw <aaronrobertshaw@git.wordpress.org>
Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>
Co-authored-by: andrewserong <andrewserong@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

I've rebased this one to address the CSS linting error regarding order.

On the choice to use :root over html or body, this does also provide the benefit of the vast majority of blocks not needing to reduce their general block style specificity. That is, if they don't specify a custom selector and rely on the default block class (.wp-block-*), styles targeting that can remain unchanged.

The restoration of 0-1-0 specificity for the margin styles within theme.scss files means they'll override some of the layout support styles which were also reduced to zero e.g. :where(.is-layout-constrained) > *

cc/ @tellthemachines and @andrewserong for your expertise on what other layout styles may also need updating

Also, I have the following list of recent PRs around reducing specificity. Are there others I've missed?

• Try reducing specificity of global styles block selector. #57841
• Reduce specificity of block library styles conflicting with block supports #59457
• Try reducing specificity of global styles selectors only. #60106
• Try reducing specificity of layout style selectors #60228
• Reduce specificity of global styles body margin reset rule. #61340
• Reset specificity of body selector when processing with postcss. #60266
• Make sure to replace all instances of :where(body) instead of just … #61602

I've pushed a commit that I think might be the minimum set of changes required to make layout styles work and maintain some more consistent specificity.

To be honest, I had a really hard time working out what should and should not be updated for the layout style selectors. Especially, when running into bugs that turned out to also be on trunk (#61849, #61846 etc)

Moving forward I think we definitely need some test coverage to ensure the correct layout styles are being applied when and where they should. These would also serve as internal documentation for anyone needing to change some aspect of our layout supports.

It's also worth noting here that this PR is being discussed in regards to what CSS specificity we should settle on for WP 6.6.

After some discussion, and taking into account the limited time before the 6.6 beta, the option to use a :root prefix seems the safest bet and appears to have majority support.

This PR should be ready to be refined, reviewed, etc with a view to landing as soon as possible.

I've updated the button block styles in 5a6a6f6. It's worth noting that the styles relating to fallback border display have been removed.

Since #61556 landed, we have access to the merged global styles data in the editor settings. A follow-up is planned to update the border panel in the editor to leverage this data and apply fallbacks only when required.

An alternative, looking to move the fallback border styles into the lib/theme.json custom css for the button block proved unsuccessful. These styles would need to sit between the core's theme.json styles and any by the theme or user. Addressing the border UX through the UI is a better solution and also means we can ship less CSS for each block that has these fallback styles.

It appears the Separator block's global styles aren't working with themes that define more than just a single background color for the block in theme.json, including TT4. This is the current behaviour on trunk so I'm not 100% sure if there has been a regression or it was intended this way for some reason. Improving this can be added to the list of follow-ups.

To progress this PR the Separator block's styles were updated in 2f70fdd, just note the odd behaviour when testing.

I've made further tweaks for the Social Links, Table, and Tag Cloud blocks. These block style variation style updates need another good test but that will have to wait until tomorrow.

(belatedly) gave this a test and all seems to be working as expected!

A draft backport PR is available in WordPress/wordpress-develop#6633. It might be easiest to close the currently pending backport for the old zero-specificity changes (WordPress/wordpress-develop#6522) then proceed with the current draft.

That sounds sensible, I went ahead and closed my PR.

Backport is ready for review over in WordPress/wordpress-develop#6633

Dev Note: WordPress 6.6 CSS Specificity

One of the goals of WordPress 6.6 is to simplify the process for theme authors to override core styles while also maintaining support for Global Styles.

Historically, high CSS specificity in core styles has made customization challenging and unpredictable, often requiring complex CSS rules to achieve desired outcomes. Development of the new section styles feature also highlighted a need for uniform CSS specificity to support nesting such styles, facilitating the creation of sophisticated, layered designs.

Uniform 0-1-0 Specificity

WordPress 6.6 introduces several changes aimed at broadly reducing CSS specificity and making it more uniform. These changes generally fall into two categories:

1. Core Block Styles
2. Theme.json / Global Styles:

Where adjustments to CSS specificity were required, they were achieved by wrapping the existing selector within :root :where(...).

Core Block Styles

The choice of 0-1-0 specificity greatly reduced the changes required to existing core block styles as blocks targeting their default .wp-block-<name> class already have the desired specificity.

Any blocks with Global Styles support using higher specificity selectors had those selectors wrapped in :root :where(...). This also applied to Block Styles (aka block style variations) and their default styles e.g. .wp-block-image.is-style-rounded img was updated to :root :where(.wp-block-image.is-style-rounded img).

Theme.json / Global Styles:

All block styles, including block style variation styles, output by Theme.json and Global Styles are now limited to 0-1-0 specificity. Layout styles, e.g. constrained, flex, flow etc., have also been limited however depending on the specific layout type and definition the final specificity varies slightly from 0-1-0 so they apply correctly.

Usage

The alignment of 0-1-0 specificity for Global Styles to default block selectors, e.g. .wp-block-<name>, greatly reduces the need for updates. It's recommended for theme and block authors to double-check their designs if they rely on custom CSS using more complex selectors.

Custom Blocks

Authors of custom blocks that opt into global styles and apply default styling via a selector with greater than 0-1-0 specificity, should update those selectors wrapping them in :root :where().

An example could be a custom list block that opts into padding block support but defines default padding via:

ul.wp-block-custom-list {
    padding: 0;
}

Without adjusting the specificity of this rule, any customizations of the block type's padding in Global Styles would be overridden. Wrapping the selector in :root :where() here would allow the style load order to determine which rule takes precedence.

// Block's stylesheet
:root :where(ul.wp-block-custom-list) { // This is a contrived example and could simply be `.wp-block-custom-list`
    padding: 0;
}

// Global Styles - Loaded after the block styles
:root :where(.wp-block-custom-list) {
    padding: 1em;
}

Block Styles (aka Block Style Variations)

Theme authors customizing Block Styles for a core block will need to limit their style's specificity so the block style continues to be configurable via Global Styles.

For example, take a theme that tweaks the border radius for the Image block's "rounded" block style:

.wp-block-image.is-style-rounded img {
    border-radius: 2em;
}

Without adjustment, this style would override any customizations made to the Rounded block style within Global Styles.

In this case, the theme can tweak its rounded image style to the following:

//. Theme style
:root :where(.wp-block-image.is-style-rounded img) {
    border-radius: 2em;
}

// Global Styles - Loaded after the block styles
:root :where(.wp-block-image.is-style-rounded img) {
    border-radius: 4px;
}

Zero-Specificity, CSS Layers, and The Future

Reducing all core styles to zero specificity was explored before settling on 0-1-0 specificity. Zero specificity unfortunately wasn't robust in the face of common reset stylesheets and required more widespread changes.

CSS Layers were also evaluated but fell short due to not being able to enforce all styles belonged to a layer. This will change in the future at which point a combination of CSS Layers and zero-specificity can be revisited to further the benefits gained in this initial reduction of CSS specificity.

More history and context can be found in this detailed discussion.

Useful Links

• CSS Specificity for WordPress 6.6
• PR CSS reducing specificity
• Section Styling Feature

The majority of themes and custom blocks should not require any updates.

I'd be very careful saying this in the Dev Note. So far, I've seen quite a few reports from people building themes where these changes have altered their designs in various ways. I'd say that every theme and block author should check their designs. It doesn't have to be OMG, the sky is falling, but it should be proactive in telling them that the reality is that this can and will affect designs where custom CSS comes into play.

Thanks for the feedback @justintadlock, appreciate it 👍

While numerous deep dives into the directory showed a majority of themes and plugins shouldn't need an update, that doesn't mean the amount needing tweaks is insignificant. It wasn't my intention to suggest otherwise or create a false sense of security so I've updated that sentence with the following.

The alignment of 0-1-0 specificity for Global Styles to default block selectors, e.g. .wp-block-<name>, greatly reduces the need for updates. It's recommended for theme and block authors to double-check their designs if they rely on custom CSS using more complex selectors.

I hope that strikes a better balance 🤞